What do these changes do?

This PR introduces a major refactoring of the users domain in the webserver, one of the oldest and most coupled parts of the codebase. Please read this description carefully.

The primary goal is to decouple user-related subdomains — such as user_preferences, user_tokens, and user_notifications — into self-contained modules. Although conceptually tied to the user, each of these features has its own database table and business logic, and they are now implemented as independent domains.

As a result, the users domain now focuses solely on user management (i.e., logic around the users table). It continues to serve as the main entry point, with its bootstrap.py function still responsible for composing and initializing all related subdomains via setup_users().

In addition, this PR includes:

• A full CSR-layer refactor of user_preferences and user_notifications
• An upgrade to the latest SQLAlchemy engine and removal of aiopg dependencies (migrate code from aiopg to asyncpg #4529)

The changes are backed by comprehensive test coverage to ensure stability.

Further details include an overview of all users domain modules, a breakdown of the new structure using user_preferences/ as an example, and notes on the user_notifications refactor.

Skeleton and CSR-layer layout:

Here an explanation of the structure using as example user_preferences/:

1. bootstrap.py (public)
   Initializes the domain into the aiohttp app: implements setup_*(app) function
   • Registers REST routes
   • Attaches handlers to on_startup / on_cleanup-like events
   • Initializes DB/service layer dependencies
   • Updates app state
2. _controller/rest/*_rest.py
   REST handler module
   • Defines aiohttp route handlers (async functions)
   • Exposes endpoints for interacting with user preferences (GET/PUT, etc.)
3. _controller/rest/_rest_exceptions.py
   REST-specific exceptions handlers:
   • Maps internal errors to HTTP responses
   • Includes well formatted and humna-readable user messages
4. _models.py
   Domain model definitions (likely ORM or DTOs):
   • Internal data representation (Pydantic models)
5. _repository.py
   Data access layer:
   • Encapsulates queries and persistence logic
   • Exposes methods to fetch/store preference data from DB
6. _service.py
   Domain logic layer:
   • Implements business logic around user preferences
   • Pure functions or service classes operating over models/repositories
7. user_preferences_service.py (public)
   Public service interface:
   • Exposes the domain’s service layer for external use
   • Acts as a façade or entry point to user_preferences from outside (e.g., from users/bootstrap.py)

Refactoring of user_notifications

• Repository layer (user_notifications._repository.py): handles: Redis commands, data serialization/deserialization, key management. Why?
  1. Data Access Pattern: The Redis operations are pure data access/persistence operations - they're interacting with the data store (Redis) just like database operations would interact with PostgreSQL.
  2. Consistency with existing pattern: Looking at your other modules:
  - user_preferences has a repository that handles database operations via FrontendUserPreferencesRepo
  - user_tokens has a repository that handles database operations via SQLAlchemy
  - The Redis operations here are functionally equivalent - they're data persistence operations
  3. Separation of Concerns
  4. Testability: Having Redis operations in a repository makes them easier to mock and test
• Service (user_notifications._service.py): Handle business logic (product filtering, backwards compatibility, notification creation logic), call repository methods
• Controller (use_notification_rest.py) : Handle HTTP concerns, validation, call service methods

Related issue/s

• Follows ♻️ webserver: Extract Pre-Registration Logic from login Domain into login_accounts #8080
• Part of migrate code from aiopg to asyncpg #4529
• Refactoring before extending functionality of https://github.com/ITISFoundation/private-issues/issues/69
• Closes Maintenance: Refactor in users domain in webserver #6913

How to test

cd services/web/server
make install-dev
pytest -vv tests/unit/**/test_*user*.py

Manual exploratory testing 🚨

• get profile
• load/save preferences
• load/save tokens
• notify-users
  • share a project between two users
  • create an organization and add a user
  • share a wallet

Dev-ops

None